maxima-discuss — Maxima discussion list

Re: [Maxima-discuss] Careful arithmetic ... was Re: +-Inf and NaN

[Raymond T. <toy...@gm...>]

On Sun, Mar 3, 2024 at 6:05 PM Richard Fateman <fa...@gm...> wrote:

> If we know how to extract and re-pack stuff into a NaN,  we can
> elaborate on something like this.  (in SBCL Maxima)
>
>   ... where I have defined cexpt for "careful expt" ...
>
> (%i2) cexpt(2.0,1000000);
>
> #<FLOATING-POINT-OVERFLOW{10038EB283}>   /* a printed message */
>
> (%o2) 2.0^1000000
>
>  /* see the result, but internally it is...  ((MEXPT SIMP
> #<FLOATING-POINT-OVERFLOW{10038EB283}>) 2.0 1000000)  */
>
> Here is the lisp definition of cexpt
>
> (defun $cexpt (x y); careful expt
>   (catch 'float-catch  (handler-bind
>             ((error
>                #'(lambda(c)
>                     (print c)  ;; just for debugging ...
>                     (throw 'float-catch  `((mexpt simp ,c) ,x  ,y)))))
>               (expt x y))))
>
> HOWEVER, running this example in SBCL sets some flags so that it
> doesn't work a second time, returning instead
> #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
> Suggestions from SBCL fans?
>
This works fine with cmucl.  I can do two calls to cexpt and get the same
overflow result each time.

(to be specific, there are 2 areas )
> 1. how to pack a pointer to, say,  the result 2.0^1000000 into a NaN.
>     so cexpt will then return that NaN as its result...
>

Can't say for sbcl, but cmucl has kernel:make-double-float that takes a
(signed-byte 32) and an (unsigned-byte 32).  The signed-byte is the upper
32 bits of a double-float and the unsigned-byte is the lower 32 bits.
kernel:double-float-bits returns these two values when given a double-float.

I would assume sbcl has the same functions but maybe in a different package
and with perhaps a different signature.

IIRC, x64 has 64-bits of address, but only 44 (?) are used.  There's a hole
in the middle somewhere so that the low(er) addresses are valid but also
the high(er) addresses (0xffffffffffffffff) are valid.  You'll have to take
that into account if you're stuffing random pointers into a NaN.  If your
pointers are in the heap, then there should probably be more than enough
space in a double-float to hold the pointer.

This is going to fail when GC happens and moves the pointed to object to a
new location.  You'll have to figure out how to keep them in sync.  Maybe a
scavenger-hook available on some systems like cmucl?

2. fix sbcl flags so that the handler still works after the first
> floating-point error..
>
> The idea then is to make "careful" versions of all floating-point
> arithmetic,
> include sin/cos/tan.
>
> Instead of using NaNs, in Maxima
> we can also intercept the float errors and put in our
> own symbolic Maxima names like inf, minf, und,
>
I think this would be way easier and GC won't get in the way when things
move.


> or perhaps we can  return intervals.
> (I'm not entirely in agreement with this abuse of 'intervals', but
> Mathematica says Sin[Infinity] is Interval[{-1,1}] .
> Of course then you need to be able to compute Sin[Interval[...]]   )
>
> RJF
>
>
> On Wed, Feb 28, 2024 at 11:14 AM Richard Fateman <fa...@gm...>
> wrote:
>
>> Yes for your 2nd and 3rd points.  I was thinking something like...
>> m:ident(4)$
>> m[2,3]:eps$
>> m[1,2]: x$
>> m^^2;
>>
>> where the vast majority of operations could be done with floats, full
>> speed.
>> Only 4 entries are non-numbers...
>>
>>
>> [1, 2*x, eps*x, 0],
>> [0, 1, 2*eps, 0],
>> [0, 0, 1, 0],
>> [0, 0, 0, 1]
>>
>> This kind of approach could be used to establish how some small parameter
>> like eps
>> might enter into the algorithm that has been in use for purely numeric
>> calcs.
>> RJF
>>
>>
>> On Wed, Feb 28, 2024 at 10:58 AM Stavros Macrakis <mac...@gm...>
>> wrote:
>>
>>> I'm not sure I see the point of encoding symbols into NaN payloads.
>>> When would you want to do this?
>>>
>>>    - If it is mostly a symbolic calculation, this seems like a very
>>>    roundabout way of invoking simplification (doesn't trap handling have a
>>>    much higher overhead than a procedure call?).
>>>    - If it is mostly a numerical calculation, do you expect that only a
>>>    small proportion of numbers will become symbolic if (say) just one of
>>>    the inputs is made symbolic? Or will most of them sooner or later become
>>>    symbolic by contagion?
>>>    - I suppose that you could use this approach to replace float64 with
>>>    bfloat. The overhead would be high, but it might be useful for seeing the
>>>    effect of higher precision on the calculation.
>>>
>>> How many numerical algorithms lend themselves to this approach? Anything
>>> with iterative convergence presumably will fail, for example.
>>>
>>>
>>>
>>> On Wed, Feb 28, 2024 at 1:39 PM Richard Fateman <fa...@gm...>
>>> wrote:
>>>
>>>> Years (decades?) ago I gave up on clever use of NaNs combined with
>>>> speed.  If trapping
>>>> is enabled, but an exception sends the processor into some painful
>>>> handler, that's
>>>> still a prospect for diagnostics. Presumably the handler is given some
>>>> return address
>>>> and maybe some other bits, and this info could be stuffed into some
>>>> payload of the
>>>> NaN's mantissa.  I have not seen it done.
>>>> One prospect that I think I've mentioned is that one could encode a
>>>> computer
>>>> algebra system into a NaN-based framework.  Floating-point numbers are
>>>> whatever
>>>> numbers they represent. A NaN is a pointer into a table that says..
>>>> this NaN is the
>>>> symbol X,   or perhaps a Lisp S-expression.  The trap handling would
>>>> call a simplifier
>>>> program when the operation is ADD of two NaNs representing X and Y, to
>>>> make a
>>>> new NaN pointing to X+Y.   etc.
>>>> It seems to me this would be a fun project, but I have not studied
>>>> current facilities, and
>>>> probably higher-level language support for this is lacking. But maybe
>>>> this is an opportunity
>>>> for Lisp.
>>>> .
>>>> rjf
>>>>
>>>> On Wed, Feb 28, 2024 at 9:51 AM Henry Baker <hb...@pi...>
>>>> wrote:
>>>>
>>>>> Re: use the mantissa of a NaN for storing info
>>>>>
>>>>>
>>>>>
>>>>> Great idea, but doesn't work in practice.
>>>>>
>>>>>
>>>>>
>>>>> The reason?
>>>>>
>>>>>
>>>>>
>>>>> The stuff you might want to store in the mantissa isn't normally
>>>>> available to the FP HW,
>>>>>
>>>>> so you would normally consider trapping.  But as I found to my
>>>>> consternation, trapping
>>>>>
>>>>> NaN's doesn't work/is useless, so you end up with an if-then-else
>>>>> expression instead of
>>>>>
>>>>> a simple HW FP op.  You've now lost most -- if not all -- of your HW
>>>>> FP performance.
>>>>>
>>>>>
>>>>>
>>>>> Part of the problem is that someone needed to do at least one PhD
>>>>> thesis on what sorts
>>>>>
>>>>> of things one might want to store in said mantissa, but to my
>>>>> knowledge, no such PhD
>>>>>
>>>>> thesis was ever written.  There's not much point in optimizing HW for
>>>>> some task that's
>>>>>
>>>>> never been researched before in SW.
>>>>>
>>>>>
>>>>>
>>>>> Re: uninitialized/missing data:
>>>>>
>>>>>
>>>>>
>>>>> Flagging uninitialized data might be about the *only* useful use for
>>>>> trapping NaN's.
>>>>>
>>>>>
>>>>>
>>>>> Missing data flags probably want to propagate transitively w/o
>>>>> trapping -- e.g., what
>>>>>
>>>>> happens in spreadsheets when some entry is blank.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Richard Fateman <fa...@gm...>
>>>>> Sent: Feb 28, 2024 8:11 AM
>>>>> To: Camm Maguire <ca...@ma...>
>>>>> Cc: Stavros Macrakis <mac...@gm...>, <
>>>>> max...@li...>, Robert Dodier <
>>>>> rob...@gm...>, <gcl...@gn...>
>>>>> Subject: Re: [Maxima-discuss] +-Inf and NaN
>>>>>
>>>>>
>>>>> Not sure about* most* users.  You can read my old article about IEEE
>>>>> 754 and programming languages.
>>>>> At least the intent for NaNs was that they would propagate through a
>>>>> computation and
>>>>> emerge only if relevant. At least under some conditions.
>>>>> I personally have no realistic use cases for using traps for numerics,
>>>>> or for propagating NaNs,
>>>>> but I'm not a professional error analyst; few if any Lisp programmers
>>>>> are... (Ray?)
>>>>> If all that is being questioned is the default enabling of trapping,
>>>>> it doesn't seem much
>>>>> of an issue.
>>>>>   It would be nice to see if we can (say) fill an "uninitialized"
>>>>> float array by
>>>>> initializing it with NaNs, or use the mantissa of a NaN for storing
>>>>> info.
>>>>> RJF
>>>>>
>>>>> On Wed, Feb 28, 2024 at 5:44 AM Camm Maguire <ca...@ma...>
>>>>> wrote:
>>>>>
>>>>>> Greetings!
>>>>>>
>>>>>> Raymond Toy <toy...@gm...> writes:
>>>>>>
>>>>>> > On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire <
>>>>>> ca...@ma...> wrote:
>>>>>> >
>>>>>> >  Greetings, and thanks to all for the very helpful feedback!
>>>>>> >
>>>>>> >  I'd also like to note in passing that the excellent SBCL out of
>>>>>> the box
>>>>>> >  triggers an error, which we separately refer to as an 'exception
>>>>>> trap',
>>>>>> >  when NaN is passed to the comparison functions, e.g. '=.  And low
>>>>>> and
>>>>>> >  behold, gcl does the same when 'trapping' is turned on, but gcl
>>>>>> turns
>>>>>> >  trapping off 'out of the box'.  NaN does not trigger an exception
>>>>>> nor
>>>>>> >
>>>>>> > I hope you will consider changing the default to trap on invalid
>>>>>> > operations so that instead of returning NaN, an error is signaled.
>>>>>> I
>>>>>> > certainly hate this behaviour, because after you do a long set of
>>>>>> > numerical computations, all the results are NaN.  I've just wasted a
>>>>>> > whole bunch of time.  This is super-annying in Javascript where you
>>>>>> > don't have an option of disabling traps.  Now you get to go through
>>>>>> > all the code and either put prints or checks for NaN to see what
>>>>>> > caused it.  What a colossal waste of time when the computer could
>>>>>> have
>>>>>> > told me.
>>>>>> >
>>>>>>
>>>>>> This is good to hear, as I was of the opposite impression that most
>>>>>> users wanted NaNs to propagate freely.
>>>>>>
>>>>>>
>>>>>> >  error when passed to '+,'*,'cos etc. but returns NaN.  This is the
>>>>>> >  current state of play.  What follows is a discussion of what it
>>>>>> means
>>>>>> >  and the best way to fit NaN into the common-lisp type lattice so
>>>>>> it does
>>>>>> >  not get in the way of the compiler.
>>>>>> >
>>>>>> >  In summary, NaN seems indistinguishable to me from an ignorable
>>>>>> error
>>>>>> >  indicator at the hardware level.  It is not conceptually a 'valid
>>>>>> input'
>>>>>> >  to any of these functions, but is a clever design to propagate the
>>>>>> error
>>>>>> >  properly when ignored.  Conceptually, it seems no different from
>>>>>> >  'ignore-errors in common-lisp.  So really the spec is not all that
>>>>>> far
>>>>>> >  away from IEEE.
>>>>>> >
>>>>>> > I suppose that that is true, but I don't think any Lisp programmer
>>>>>> > would wrap their entire programs in a ignore-errors form.  That's
>>>>>> > usually one done on a very limited scope.  Having traps off to get
>>>>>> > NaN, is basically the same idea.
>>>>>> >
>>>>>>
>>>>>> Wrapping code in ignore-errors is totally unnecessary.  I can insert a
>>>>>> specific handler within GCL's type-error mechanism to skip the error
>>>>>> when testing NaN depending on a global variable setting.  One question
>>>>>> is whether such a setting governing skipping a lisp error should be
>>>>>> the
>>>>>> same as or distinct from the setting enabling hardware traps.
>>>>>>
>>>>>> >  As for common-lisp types, the obvious path is what GCL and others
>>>>>> >  currently implement, double precision NaN is of type 'long-float
>>>>>> and
>>>>>> >  hence 'number.  This actually means that lisp will *stray* from
>>>>>> IEEE and
>>>>>> >
>>>>>> > I think one thing that confuses me, is that for gcl, single-float =
>>>>>> > double-float = double precision.  short-float is single precision.
>>>>>> I
>>>>>> > think long-float is double-precision.  I think all other lisps have
>>>>>> > single-float = single precision, double-float = double precision.
>>>>>> > Short-float is usually the same as single-float.  Long-float is
>>>>>> > usually double-float, if they don't have a separate long-float (like
>>>>>> > clisp).
>>>>>> >
>>>>>> > So whenever you say long-float, I sometimes think of actual
>>>>>> > long-floats like clisp, but you're actually talking about
>>>>>> > double-precision floats.
>>>>>>
>>>>>> Thanks, this needs to be cleaned up.  I think single-float should be
>>>>>> short-float (e.g. 4 bytes).
>>>>>>
>>>>>> I suppose in principle each of these could be distinct, long-float
>>>>>> could
>>>>>> be long double, supported on most machines, and short float could be a
>>>>>> new 16bit float :-).  It looks like the next GCL version will be able
>>>>>> to
>>>>>> pass 4 unboxed arguments of the same size on 64bit machines, 'object'
>>>>>> (e.g. void *), unsigned long, double, and float complex.  I have space
>>>>>> in the argument descriptor for 4 such formats, but on 32bit machines,
>>>>>> we
>>>>>> only have three useful ones, given the absence of 'short float
>>>>>> complex'.
>>>>>>
>>>>>> Take care,
>>>>>> --
>>>>>> Camm Maguire
>>>>>> ca...@ma...
>>>>>>
>>>>>> ==========================================================================
>>>>>> "The earth is but one country, and mankind its citizens."  --
>>>>>> Baha'u'llah
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>


-- 
Ray

Re: [Maxima-discuss] Careful arithmetic ... was Re: +-Inf and NaN

[Stavros M. <mac...@gm...>]

Re this:

On Sun, Mar 3, 2024 at 9:25 PM Henry Baker <hb...@pi...> wrote:

> ...
>
> asin(0.5) => %pi/6 + 2*%pi*%r103
>
>
>
> '%pi' is the symbol for pi; %r103 is a generated variable with is declared
> to be an integer.
>
...

I think that's a completely different issue that deserves its own thread if
you want to open it.

The *to_poly_solve* package already generates results like this:

%solve([sin(x)=1/2],x);
%union([x = 2*%pi*%z1380+(5*%pi)/6],
       [x = 2*%pi*%z1419+%pi/6])


Simplifying expressions involving multiple %zNNN's is a challenge....

[Maxima-discuss] Careful arithmetic ... was Re: +-Inf and NaN

[Henry B. <hb...@pi...>]

Hi Richard:

Very interesting!

How much cleverness do you want to put into this?

E.g.,

asin(0.5) => %pi/6 + 2*%pi*%r103

'%pi' is the symbol for pi; %r103 is a generated variable with is declared to be an integer.

One could also 'hide' the polynomial for an algebraic number inside an NaN...

-----Original Message-----
From: Richard Fateman <fa...@gm...>
Sent: Mar 3, 2024 6:03 PM
To: <max...@li...> <max...@li...>
Cc: Richard Fateman <fa...@gm...>, <gcl...@gn...>
Subject: [Maxima-discuss] Careful arithmetic ... was Re: +-Inf and NaN

If we know how to extract and re-pack stuff into a NaN,  we can 
elaborate on something like this.  (in SBCL Maxima)

  ... where I have defined cexpt for "careful expt" ...

(%i2) cexpt(2.0,1000000);

#<FLOATING-POINT-OVERFLOW{10038EB283}>   /* a printed message */ 

(%o2) 2.0^1000000   
 
 /* see the result, but internally it is...  ((MEXPT SIMP #<FLOATING-POINT-OVERFLOW{10038EB283}>) 2.0 1000000)  */
 
Here is the lisp definition of cexpt

(defun $cexpt (x y); careful expt
  (catch 'float-catch  (handler-bind
            ((error
               #'(lambda(c)
                    (print c)  ;; just for debugging ...
                    (throw 'float-catch  `((mexpt simp ,c) ,x  ,y)))))
              (expt x y))))
 
HOWEVER, running this example in SBCL sets some flags so that it 
doesn't work a second time, returning instead #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
Suggestions from SBCL fans?
(to be specific, there are 2 areas )
1. how to pack a pointer to, say,  the result 2.0^1000000 into a NaN.
    so cexpt will then return that NaN as its result...
2. fix sbcl flags so that the handler still works after the first floating-point error..
 
The idea then is to make "careful" versions of all floating-point arithmetic,
include sin/cos/tan. 
 
Instead of using NaNs, in Maxima
we can also intercept the float errors and put in our
own symbolic Maxima names like inf, minf, und,  
 
or perhaps we can  return intervals.
(I'm not entirely in agreement with this abuse of 'intervals', but
Mathematica says Sin[Infinity] is Interval[{-1,1}] .
Of course then you need to be able to compute Sin[Interval[...]]   )
 
RJF
 




On Wed, Feb 28, 2024 at 11:14 AM Richard Fateman <fa...@gm... (mailto:fa...@gm...)> wrote:
Yes for your 2nd and 3rd points.  I was thinking something like...m:ident(4)$
m[2,3]:eps$
m[1,2]: x$
m^^2;
 
where the vast majority of operations could be done with floats, full speed.
Only 4 entries are non-numbers...
 

[1, 2*x, eps*x, 0],
[0, 1, 2*eps, 0],
[0, 0, 1, 0],
[0, 0, 0, 1]


This kind of approach could be used to establish how some small parameter like eps
might enter into the algorithm that has been in use for purely numeric calcs.
RJF
 


On Wed, Feb 28, 2024 at 10:58 AM Stavros Macrakis <mac...@gm... (mailto:mac...@gm...)> wrote:
I'm not sure I see the point of encoding symbols into NaN payloads.
When would you want to do this?
  *  If it is mostly a symbolic calculation, this seems like a very roundabout way of invoking simplification (doesn't trap handling have a much higher overhead than a procedure call?).
  *  If it is mostly a numerical calculation, do you expect that only a small proportion of numbers will become symbolic if (say) just one of the inputs is made symbolic? Or will most of them sooner or later become symbolic by contagion?
  *  I suppose that you could use this approach to replace float64 with bfloat. The overhead would be high, but it might be useful for seeing the effect of higher precision on the calculation.


How many numerical algorithms lend themselves to this approach? Anything with iterative convergence presumably will fail, for example.
 
 
 


On Wed, Feb 28, 2024 at 1:39 PM Richard Fateman <fa...@gm... (mailto:fa...@gm...)> wrote:
Years (decades?) ago I gave up on clever use of NaNs combined with speed.  If trappingis enabled, but an exception sends the processor into some painful handler, that's
still a prospect for diagnostics. Presumably the handler is given some return address
and maybe some other bits, and this info could be stuffed into some payload of the
NaN's mantissa.  I have not seen it done.
One prospect that I think I've mentioned is that one could encode a computer
algebra system into a NaN-based framework.  Floating-point numbers are whatever
numbers they represent. A NaN is a pointer into a table that says.. this NaN is the
symbol X,   or perhaps a Lisp S-expression.  The trap handling would call a simplifier
program when the operation is ADD of two NaNs representing X and Y, to make a
new NaN pointing to X+Y.   etc.
It seems to me this would be a fun project, but I have not studied current facilities, and
probably higher-level language support for this is lacking. But maybe this is an opportunity
for Lisp.
.
rjf


On Wed, Feb 28, 2024 at 9:51 AM Henry Baker <hb...@pi... (mailto:hb...@pi...)> wrote:
Re: use the mantissa of a NaN for storing info

Great idea, but doesn't work in practice.

The reason?

The stuff you might want to store in the mantissa isn't normally available to the FP HW,
so you would normally consider trapping.  But as I found to my consternation, trapping
NaN's doesn't work/is useless, so you end up with an if-then-else expression instead of
a simple HW FP op.  You've now lost most -- if not all -- of your HW FP performance.

Part of the problem is that someone needed to do at least one PhD thesis on what sorts
of things one might want to store in said mantissa, but to my knowledge, no such PhD
thesis was ever written.  There's not much point in optimizing HW for some task that's
never been researched before in SW.

Re: uninitialized/missing data:

Flagging uninitialized data might be about the *only* useful use for trapping NaN's.

Missing data flags probably want to propagate transitively w/o trapping -- e.g., what
happens in spreadsheets when some entry is blank.


-----Original Message-----
From: Richard Fateman <fa...@gm... (mailto:fa...@gm...)>
Sent: Feb 28, 2024 8:11 AM
To: Camm Maguire <ca...@ma... (mailto:ca...@ma...)>
Cc: Stavros Macrakis <mac...@gm... (mailto:mac...@gm...)>, <max...@li... (mailto:max...@li...)>, Robert Dodier <rob...@gm... (mailto:rob...@gm...)>, <gcl...@gn... (mailto:gcl...@gn...)>
Subject: Re: [Maxima-discuss] +-Inf and NaN

Not sure about most users.  You can read my old article about IEEE 754 and programming languages.  At least the intent for NaNs was that they would propagate through a computation and
emerge only if relevant. At least under some conditions.
I personally have no realistic use cases for using traps for numerics, or for propagating NaNs,
but I'm not a professional error analyst; few if any Lisp programmers are... (Ray?)
If all that is being questioned is the default enabling of trapping, it doesn't seem much
of an issue.
  It would be nice to see if we can (say) fill an "uninitialized" float array by
initializing it with NaNs, or use the mantissa of a NaN for storing info.
RJF


On Wed, Feb 28, 2024 at 5:44 AM Camm Maguire <ca...@ma... (mailto:ca...@ma...)> wrote:
Greetings!

Raymond Toy <toy...@gm... (mailto:toy...@gm...)> writes:

> On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire <ca...@ma... (mailto:ca...@ma...)> wrote:
>
>  Greetings, and thanks to all for the very helpful feedback!
>
>  I'd also like to note in passing that the excellent SBCL out of the box
>  triggers an error, which we separately refer to as an 'exception trap',
>  when NaN is passed to the comparison functions, e.g. '=.  And low and
>  behold, gcl does the same when 'trapping' is turned on, but gcl turns
>  trapping off 'out of the box'.  NaN does not trigger an exception nor
>
> I hope you will consider changing the default to trap on invalid
> operations so that instead of returning NaN, an error is signaled.  I
> certainly hate this behaviour, because after you do a long set of
> numerical computations, all the results are NaN.  I've just wasted a
> whole bunch of time.  This is super-annying in Javascript where you
> don't have an option of disabling traps.  Now you get to go through
> all the code and either put prints or checks for NaN to see what
> caused it.  What a colossal waste of time when the computer could have
> told me.
>

This is good to hear, as I was of the opposite impression that most
users wanted NaNs to propagate freely.


>  error when passed to '+,'*,'cos etc. but returns NaN.  This is the
>  current state of play.  What follows is a discussion of what it means
>  and the best way to fit NaN into the common-lisp type lattice so it does
>  not get in the way of the compiler.
>
>  In summary, NaN seems indistinguishable to me from an ignorable error
>  indicator at the hardware level.  It is not conceptually a 'valid input'
>  to any of these functions, but is a clever design to propagate the error
>  properly when ignored.  Conceptually, it seems no different from
>  'ignore-errors in common-lisp.  So really the spec is not all that far
>  away from IEEE.
>
> I suppose that that is true, but I don't think any Lisp programmer
> would wrap their entire programs in a ignore-errors form.  That's
> usually one done on a very limited scope.  Having traps off to get
> NaN, is basically the same idea.
>

Wrapping code in ignore-errors is totally unnecessary.  I can insert a
specific handler within GCL's type-error mechanism to skip the error
when testing NaN depending on a global variable setting.  One question
is whether such a setting governing skipping a lisp error should be the
same as or distinct from the setting enabling hardware traps.

>  As for common-lisp types, the obvious path is what GCL and others
>  currently implement, double precision NaN is of type 'long-float and
>  hence 'number.  This actually means that lisp will *stray* from IEEE and
>
> I think one thing that confuses me, is that for gcl, single-float =
> double-float = double precision.  short-float is single precision.  I
> think long-float is double-precision.  I think all other lisps have
> single-float = single precision, double-float = double precision.
> Short-float is usually the same as single-float.  Long-float is
> usually double-float, if they don't have a separate long-float (like
> clisp).
>
> So whenever you say long-float, I sometimes think of actual
> long-floats like clisp, but you're actually talking about
> double-precision floats.

Thanks, this needs to be cleaned up.  I think single-float should be
short-float (e.g. 4 bytes).

I suppose in principle each of these could be distinct, long-float could
be long double, supported on most machines, and short float could be a
new 16bit float :-).  It looks like the next GCL version will be able to
pass 4 unboxed arguments of the same size on 64bit machines, 'object'
(e.g. void *), unsigned long, double, and float complex.  I have space
in the argument descriptor for 4 such formats, but on 32bit machines, we
only have three useful ones, given the absence of 'short float complex'.

Take care,
-- 
Camm Maguire                                        ca...@ma... (mailto:ca...@ma...)
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

[Maxima-discuss] Careful arithmetic ... was Re: +-Inf and NaN

[Richard F. <fa...@gm...>]

If we know how to extract and re-pack stuff into a NaN,  we can
elaborate on something like this.  (in SBCL Maxima)

  ... where I have defined cexpt for "careful expt" ...

(%i2) cexpt(2.0,1000000);

#<FLOATING-POINT-OVERFLOW{10038EB283}>   /* a printed message */

(%o2) 2.0^1000000

 /* see the result, but internally it is...  ((MEXPT SIMP
#<FLOATING-POINT-OVERFLOW{10038EB283}>) 2.0 1000000)  */

Here is the lisp definition of cexpt

(defun $cexpt (x y); careful expt
  (catch 'float-catch  (handler-bind
            ((error
               #'(lambda(c)
                    (print c)  ;; just for debugging ...
                    (throw 'float-catch  `((mexpt simp ,c) ,x  ,y)))))
              (expt x y))))

HOWEVER, running this example in SBCL sets some flags so that it
doesn't work a second time, returning instead
#.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
Suggestions from SBCL fans?
(to be specific, there are 2 areas )
1. how to pack a pointer to, say,  the result 2.0^1000000 into a NaN.
    so cexpt will then return that NaN as its result...
2. fix sbcl flags so that the handler still works after the first
floating-point error..

The idea then is to make "careful" versions of all floating-point
arithmetic,
include sin/cos/tan.

Instead of using NaNs, in Maxima
we can also intercept the float errors and put in our
own symbolic Maxima names like inf, minf, und,

or perhaps we can  return intervals.
(I'm not entirely in agreement with this abuse of 'intervals', but
Mathematica says Sin[Infinity] is Interval[{-1,1}] .
Of course then you need to be able to compute Sin[Interval[...]]   )

RJF


On Wed, Feb 28, 2024 at 11:14 AM Richard Fateman <fa...@gm...> wrote:

> Yes for your 2nd and 3rd points.  I was thinking something like...
> m:ident(4)$
> m[2,3]:eps$
> m[1,2]: x$
> m^^2;
>
> where the vast majority of operations could be done with floats, full
> speed.
> Only 4 entries are non-numbers...
>
>
> [1, 2*x, eps*x, 0],
> [0, 1, 2*eps, 0],
> [0, 0, 1, 0],
> [0, 0, 0, 1]
>
> This kind of approach could be used to establish how some small parameter
> like eps
> might enter into the algorithm that has been in use for purely numeric
> calcs.
> RJF
>
>
> On Wed, Feb 28, 2024 at 10:58 AM Stavros Macrakis <mac...@gm...>
> wrote:
>
>> I'm not sure I see the point of encoding symbols into NaN payloads.
>> When would you want to do this?
>>
>>    - If it is mostly a symbolic calculation, this seems like a very
>>    roundabout way of invoking simplification (doesn't trap handling have a
>>    much higher overhead than a procedure call?).
>>    - If it is mostly a numerical calculation, do you expect that only a
>>    small proportion of numbers will become symbolic if (say) just one of
>>    the inputs is made symbolic? Or will most of them sooner or later become
>>    symbolic by contagion?
>>    - I suppose that you could use this approach to replace float64 with
>>    bfloat. The overhead would be high, but it might be useful for seeing the
>>    effect of higher precision on the calculation.
>>
>> How many numerical algorithms lend themselves to this approach? Anything
>> with iterative convergence presumably will fail, for example.
>>
>>
>>
>> On Wed, Feb 28, 2024 at 1:39 PM Richard Fateman <fa...@gm...>
>> wrote:
>>
>>> Years (decades?) ago I gave up on clever use of NaNs combined with
>>> speed.  If trapping
>>> is enabled, but an exception sends the processor into some painful
>>> handler, that's
>>> still a prospect for diagnostics. Presumably the handler is given some
>>> return address
>>> and maybe some other bits, and this info could be stuffed into some
>>> payload of the
>>> NaN's mantissa.  I have not seen it done.
>>> One prospect that I think I've mentioned is that one could encode a
>>> computer
>>> algebra system into a NaN-based framework.  Floating-point numbers are
>>> whatever
>>> numbers they represent. A NaN is a pointer into a table that says.. this
>>> NaN is the
>>> symbol X,   or perhaps a Lisp S-expression.  The trap handling would
>>> call a simplifier
>>> program when the operation is ADD of two NaNs representing X and Y, to
>>> make a
>>> new NaN pointing to X+Y.   etc.
>>> It seems to me this would be a fun project, but I have not studied
>>> current facilities, and
>>> probably higher-level language support for this is lacking. But maybe
>>> this is an opportunity
>>> for Lisp.
>>> .
>>> rjf
>>>
>>> On Wed, Feb 28, 2024 at 9:51 AM Henry Baker <hb...@pi...>
>>> wrote:
>>>
>>>> Re: use the mantissa of a NaN for storing info
>>>>
>>>>
>>>>
>>>> Great idea, but doesn't work in practice.
>>>>
>>>>
>>>>
>>>> The reason?
>>>>
>>>>
>>>>
>>>> The stuff you might want to store in the mantissa isn't normally
>>>> available to the FP HW,
>>>>
>>>> so you would normally consider trapping.  But as I found to my
>>>> consternation, trapping
>>>>
>>>> NaN's doesn't work/is useless, so you end up with an if-then-else
>>>> expression instead of
>>>>
>>>> a simple HW FP op.  You've now lost most -- if not all -- of your HW FP
>>>> performance.
>>>>
>>>>
>>>>
>>>> Part of the problem is that someone needed to do at least one PhD
>>>> thesis on what sorts
>>>>
>>>> of things one might want to store in said mantissa, but to my
>>>> knowledge, no such PhD
>>>>
>>>> thesis was ever written.  There's not much point in optimizing HW for
>>>> some task that's
>>>>
>>>> never been researched before in SW.
>>>>
>>>>
>>>>
>>>> Re: uninitialized/missing data:
>>>>
>>>>
>>>>
>>>> Flagging uninitialized data might be about the *only* useful use for
>>>> trapping NaN's.
>>>>
>>>>
>>>>
>>>> Missing data flags probably want to propagate transitively w/o trapping
>>>> -- e.g., what
>>>>
>>>> happens in spreadsheets when some entry is blank.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Richard Fateman <fa...@gm...>
>>>> Sent: Feb 28, 2024 8:11 AM
>>>> To: Camm Maguire <ca...@ma...>
>>>> Cc: Stavros Macrakis <mac...@gm...>, <
>>>> max...@li...>, Robert Dodier <
>>>> rob...@gm...>, <gcl...@gn...>
>>>> Subject: Re: [Maxima-discuss] +-Inf and NaN
>>>>
>>>>
>>>> Not sure about* most* users.  You can read my old article about IEEE
>>>> 754 and programming languages.
>>>> At least the intent for NaNs was that they would propagate through a
>>>> computation and
>>>> emerge only if relevant. At least under some conditions.
>>>> I personally have no realistic use cases for using traps for numerics,
>>>> or for propagating NaNs,
>>>> but I'm not a professional error analyst; few if any Lisp programmers
>>>> are... (Ray?)
>>>> If all that is being questioned is the default enabling of trapping, it
>>>> doesn't seem much
>>>> of an issue.
>>>>   It would be nice to see if we can (say) fill an "uninitialized" float
>>>> array by
>>>> initializing it with NaNs, or use the mantissa of a NaN for storing
>>>> info.
>>>> RJF
>>>>
>>>> On Wed, Feb 28, 2024 at 5:44 AM Camm Maguire <ca...@ma...>
>>>> wrote:
>>>>
>>>>> Greetings!
>>>>>
>>>>> Raymond Toy <toy...@gm...> writes:
>>>>>
>>>>> > On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire <ca...@ma...>
>>>>> wrote:
>>>>> >
>>>>> >  Greetings, and thanks to all for the very helpful feedback!
>>>>> >
>>>>> >  I'd also like to note in passing that the excellent SBCL out of the
>>>>> box
>>>>> >  triggers an error, which we separately refer to as an 'exception
>>>>> trap',
>>>>> >  when NaN is passed to the comparison functions, e.g. '=.  And low
>>>>> and
>>>>> >  behold, gcl does the same when 'trapping' is turned on, but gcl
>>>>> turns
>>>>> >  trapping off 'out of the box'.  NaN does not trigger an exception
>>>>> nor
>>>>> >
>>>>> > I hope you will consider changing the default to trap on invalid
>>>>> > operations so that instead of returning NaN, an error is signaled.  I
>>>>> > certainly hate this behaviour, because after you do a long set of
>>>>> > numerical computations, all the results are NaN.  I've just wasted a
>>>>> > whole bunch of time.  This is super-annying in Javascript where you
>>>>> > don't have an option of disabling traps.  Now you get to go through
>>>>> > all the code and either put prints or checks for NaN to see what
>>>>> > caused it.  What a colossal waste of time when the computer could
>>>>> have
>>>>> > told me.
>>>>> >
>>>>>
>>>>> This is good to hear, as I was of the opposite impression that most
>>>>> users wanted NaNs to propagate freely.
>>>>>
>>>>>
>>>>> >  error when passed to '+,'*,'cos etc. but returns NaN.  This is the
>>>>> >  current state of play.  What follows is a discussion of what it
>>>>> means
>>>>> >  and the best way to fit NaN into the common-lisp type lattice so it
>>>>> does
>>>>> >  not get in the way of the compiler.
>>>>> >
>>>>> >  In summary, NaN seems indistinguishable to me from an ignorable
>>>>> error
>>>>> >  indicator at the hardware level.  It is not conceptually a 'valid
>>>>> input'
>>>>> >  to any of these functions, but is a clever design to propagate the
>>>>> error
>>>>> >  properly when ignored.  Conceptually, it seems no different from
>>>>> >  'ignore-errors in common-lisp.  So really the spec is not all that
>>>>> far
>>>>> >  away from IEEE.
>>>>> >
>>>>> > I suppose that that is true, but I don't think any Lisp programmer
>>>>> > would wrap their entire programs in a ignore-errors form.  That's
>>>>> > usually one done on a very limited scope.  Having traps off to get
>>>>> > NaN, is basically the same idea.
>>>>> >
>>>>>
>>>>> Wrapping code in ignore-errors is totally unnecessary.  I can insert a
>>>>> specific handler within GCL's type-error mechanism to skip the error
>>>>> when testing NaN depending on a global variable setting.  One question
>>>>> is whether such a setting governing skipping a lisp error should be the
>>>>> same as or distinct from the setting enabling hardware traps.
>>>>>
>>>>> >  As for common-lisp types, the obvious path is what GCL and others
>>>>> >  currently implement, double precision NaN is of type 'long-float and
>>>>> >  hence 'number.  This actually means that lisp will *stray* from
>>>>> IEEE and
>>>>> >
>>>>> > I think one thing that confuses me, is that for gcl, single-float =
>>>>> > double-float = double precision.  short-float is single precision.  I
>>>>> > think long-float is double-precision.  I think all other lisps have
>>>>> > single-float = single precision, double-float = double precision.
>>>>> > Short-float is usually the same as single-float.  Long-float is
>>>>> > usually double-float, if they don't have a separate long-float (like
>>>>> > clisp).
>>>>> >
>>>>> > So whenever you say long-float, I sometimes think of actual
>>>>> > long-floats like clisp, but you're actually talking about
>>>>> > double-precision floats.
>>>>>
>>>>> Thanks, this needs to be cleaned up.  I think single-float should be
>>>>> short-float (e.g. 4 bytes).
>>>>>
>>>>> I suppose in principle each of these could be distinct, long-float
>>>>> could
>>>>> be long double, supported on most machines, and short float could be a
>>>>> new 16bit float :-).  It looks like the next GCL version will be able
>>>>> to
>>>>> pass 4 unboxed arguments of the same size on 64bit machines, 'object'
>>>>> (e.g. void *), unsigned long, double, and float complex.  I have space
>>>>> in the argument descriptor for 4 such formats, but on 32bit machines,
>>>>> we
>>>>> only have three useful ones, given the absence of 'short float
>>>>> complex'.
>>>>>
>>>>> Take care,
>>>>> --
>>>>> Camm Maguire
>>>>> ca...@ma...
>>>>>
>>>>> ==========================================================================
>>>>> "The earth is but one country, and mankind its citizens."  --
>>>>> Baha'u'llah
>>>>
>>>>
>>>>
>>>

Re: [Maxima-discuss] Maplist question

[Stavros M. <mac...@gm...>]

*maplist*, by default (*inflag:false*) operates on the *visible* structure
of the expression, which in this case is "-"(x1). You can "recover" the
minus sign using *op*: *op(-x1) => "-"*.

If you want to operate on the *internal* structure of the expression (which
is usually more convenient for programmatic manipulation), set *inflag:true*,
and then *op(-x1) => "*"* and *args(-x1) => [-1, x1]*.

On Sun, Mar 3, 2024 at 6:42 PM Dan Stanger <dan...@gm...>
wrote:

> Hello All,
> maplist(lambda([u],u),-x1)
> returns the list [x1]. Shouldn't it be [-x1]? If [x1] is correct, is there
> a way to recover the minus sign?
> Dan Stanger
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

[Maxima-discuss] Maplist question

[Dan S. <dan...@gm...>]

Hello All,
maplist(lambda([u],u),-x1)
returns the list [x1]. Shouldn't it be [-x1]? If [x1] is correct, is there
a way to recover the minus sign?
Dan Stanger

Re: [Maxima-discuss] Using Maxima to delete files and directories in a local machine.

[Gunter K. <gu...@pe...>]

My guess is that he wanted to do a

for i in directory("C:\\Users\\Usario") do display(i);

instead.

Kind regards,

   Gunter.

Re: [Maxima-discuss] Using Maxima to delete files and directories in a local machine.

[Wolfgang D. <wol...@da...>]

Am 01.03.24 um 18:23 schrieb El Observatorio De Matemática:
> Hi list
> 
> I want to handle a folder with more than 70000 files and 50000 
> directories and delete from it several files and directories using 
> Maxima, if it is possible.
> There is a package in contrib named operatingsystem that potentially can 
> do this task but i can not figure out how to use it.

That package was introduced by me, cause I had to use some filesystem 
operations and there was no package - but I am not a lisp expert.

> (%i3) for i in "C:\Users\Usuario\Documents\Trabajos en 
> wxmaxima\MiscRepo\OldSchool\OtherNibble\RosettaCodeData-main\Task\Sudoku" do

Your 'for' loop is no valid Maxima code. Exec 'describe("for");' for the 
syntax. A valid example - why do you need the for loop? - may be:


(%i30) for i in ["C:\\Users\\Usario"] do display(i);
                               i = C:\Users\Usario

(%o30)                               done

Attention: A single "\" is an escape character, so you must use "\\" 
instead, otherwise it would not be shown:

(%i31) for i in ["C:\Users\Usario"] do display(i);
                                i = C:UsersUsario

(%o31)                               done

Or - as you told - a "/" works instead:

(%i32)  for i in ["C:/Users/Usario"] do display(i);
                               i = C:/Users/Usario

Best regards, Wolfgang

P.S. If you need to delete many directories, using system() with a 
operating specific command - like "rm -r directories" on Linux/Unix or 
"deltree directories" on Windows might be easier.

Re: [Maxima-discuss] Using Maxima to delete files and directories in a local machine.

[Robert D. <rob...@gm...>]

On Fri, Mar 1, 2024 at 8:33 PM El Observatorio De Matemática
<obs...@gm...> wrote:

>         find "$subdir" -type d ! \( -name 'Common-Lisp' -o -name 'Maxima' \) -exec rm -r {} +

I don't understand exactly what you need to do, but my advice about
problems of this kind is to first use the script to identify the files
that are targeted, and just print out their names. Then review the
list of names and then do a simpler loop over the list to actually
delete them. Something like

$ find "$subdir" -type d ... other criteria go here ... -print

and then, when the list looks right, capture it in a shell variable
via backticks; note that !! is the immediately preceding command,
executed again.

$ a=`!!`

and then actually remove the items in the list:

$ rm $a

Same basic idea applies to Maxima or Python or whatever -- review the
list before making an irreversible change.

Hope this helps,

Robert

Re: [Maxima-discuss] Using Maxima to delete files and directories in a local machine.

[El O. De M. <obs...@gm...>]

I could not adapt the examples to what i want.

I tried to use the assistance of LLMs and went to test the following:

#!/bin/bash

# Specify the root directory
root_directory="C:/Users/Usuario/Downloads/Task"

# Loop through each subdirectory
for subdir in "$root_directory"/*; do
    if [ -d "$subdir" ]; then
        # Run the find command to delete directories in each subdirectory
        find "$subdir" -type d ! \( -name 'Common-Lisp' -o -name 'Maxima' \)
-exec rm -r {} +
    fi
done

but does not run in vscode because the path can not be found

By the way, the file i want to modify can be found here:
https://github.com/acmeism/RosettaCodeData/tree/main/Task

I think i must learn more about command line commands.

Best regards

El vie, 1 mar 2024 a las 13:23, Michel Talon (<ta...@lp...>)
escribió:

> Like this:
>
> Zbox:~$ mkdir A
>
> Zbox:~$ maxima -q
> (%i1) load("operatingsystem");
> (%o1)
> /usr/share/maxima/5.42.2/share/contrib/operatingsystem/operatingsystem.mac
> (%i2) for i from 1 thru 10 do mkdir(string(A/concat(B,i)));
> (%o2)                                done
> (%i3) for i from 1 thru 10 do if oddp(i) then rmdir(string(A/concat(B,i)));
> (%o3)                                done
> (%i4)
>
> Exit maxima
>
> Zbox:~$ ls A
> B10  B2  B4  B6  B8
>
> Le 01/03/2024 à 18:23, El Observatorio De Matemática a écrit :
> > Hi list
> >
> > I want to handle a folder with more than 70000 files and 50000
> > directories and delete from it several files and directories using
> > Maxima, if it is possible.
> > There is a package in contrib named operatingsystem that potentially
> > can do this task but i can not figure out how to use it.
> >
> --
> Michel Talon
>
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] +-Inf and NaN

[Richard F. <fa...@gm...>]

I realized that I'd wrestled with this many years ago, and found something..
I sent Camm a file with tentative solution outline used for Allegro CL. (I
can send to others on request...)

Here's the nub of it. It is relying on compiler optimization to break the
abstraction,
and it works to decode a NaN in (at least) SBCL as well.


(defun dfloat2bits(x &aux     (ans (make-array 64 :element-type
'(unsigned-byte 1))))

  (declare(optimize (speed 3)(safety 0))  ;; important

 (type (simple-array (unsigned-byte 1)(64)) x))  ;; a lie, if x is a double
float.

  (dotimes (i 64 ans)
        (declare (fixnum i))
        (setf (aref ans i) (aref x i))))

On Fri, Mar 1, 2024 at 10:54 AM Richard Fateman <fa...@gm...> wrote:

> In order to use NaN mantissas as payloads for other data,
> I think we need something to break the abstraction. Are these features
> available in any lisp?
>
<snip>

Re: [Maxima-discuss] +-Inf and NaN

[Henry B. <hb...@pi...>]

There's at least one library which provides for 'symbolic' NaN's in Rust:

https://crates.io/crates/ananas

"Put arbitrary bytes in your NaNs!"

"The NaN payload is ignored no longer! Using ananas you can imbue entirely new meaning to your NaNs."

"We can put and take out arbitrary bytes into NaNs, encoded as f32. Two bytes are stored in each f32 number"

"NaNs are propagated and this maintains the payload"

"This can produce strange behaviour when two NaNs meet, such as loss of commutativity"

---
https://crates.io/crates/nan-tag

"A library for NaN-tagged pointers in Rust. The library supports both borrowed and owned pointers"

https://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations

"Initially, all JavaScript implementations used tagged pointers to represent JS values. This is a old trick that comes from the observation that allocated memory takes up at least 4 or 8 bytes, and are aligned in such a way that the least significant bit or three will be zero."

"JavaScriptCore, the implementation used by WebKit, switched from tagged pointers to a "nan-boxed" format."

---
https://crates.io/crates/boxing

"An easy-to-use, cross-platform library for pointer and NaN boxing data - storing other data values in the unused portions of a float or pointer."

---
https://crates.io/crates/nanval

"A no_std, zero-dependency crate for the creation and handling of NaN-tagged 64-bit floating-point values"

https://sean.cm/a/nan-boxing

-----Original Message-----
From: Richard Fateman <fa...@gm...>
Sent: Mar 1, 2024 10:55 AM
To: Matt Kaufmann <kau...@cs...>
Cc: Stavros Macrakis <mac...@gm...>, Robert Dodier <rob...@gm...>, <gcl...@gn...>, <max...@li...>
Subject: Re: [Maxima-discuss] +-Inf and NaN

In order to use NaN mantissas as payloads for other data,
I think we need something to break the abstraction. Are these features
available in any lisp?
I would think that given a NaN N,   that we could look at its insides by
(integer-decode-float N)
   but (following (setf sb-int:set-floating-point-modes :traps nil) 
SBCL says "Can't decode NaN or infinity")
... normally integer-decode-float  would return 3 values. 
mantissa, exponent, sign.
 
 So fixing it would allow us to "read" the payload.
Actually we may need 2,  to decode a single and a double...  integer-decode-single-float  etc.
Or maybe just (decode-double-nan...) to give just the mantissa.
 
 
The reverse of this could look like a functional program...
(construct-double-float-from-integers  mantissa exponent sign)
or destructive one(s)
(insert-single-mantissa target value)
(insert-single-exponent target value)
... etc. double..
 
or (setf (integer-mantissa N)  value)
 
These facilities would make it feasible to use NaNs for something..
Thanks.
 
RJF
 
 
 
.
 

On Fri, Mar 1, 2024 at 8:52 AM Matt Kaufmann <kau...@cs... (mailto:kau...@cs...)> wrote:
Hi Camm,

Since this thread has discussed floating-point exceptions, I'll weigh
in only by requesting that such behavior will continue to be
configurable.  Specifically, in ACL2 built using GCL 2.6.12
(Version_2_6_13pre131), where compilation uses safety 0, then
evaluation of the following form at start-up gives the behavior I want
-- in particular, an error when there is floating-point overflow or
division by zero.

(fpe:break-on-floating-point-exceptions
 :floating-point-overflow t
 :floating-point-invalid-operation t)

For example, when I evaluate the definitions

(defun f ()
  (let ((y (* most-positive-double-float most-positive-double-float)))
    (= (- y y) 0.0d0)))

and

(defun g ()
  (= (/ 0.0d0 0.0d0) 0.0d0))

and then compile f and g, then the evaluations of (f) and (g) both
cause errors, which is what I want.  (If f and g are compiled in gcl
with safety 0 but are called without first calling
fpe:break-on-floating-point-exceptions, then there is no error.)

By the way, you asked, regarding other Lisps:

> Can one access/manipulate nan at the lisp prompt level?

See attached, which I think answers your question positively for
LispWorks, Allegro CL, and CCL, but perhaps negatively for SBCL and
CMUCL.

Thanks,
Matt
Camm Maguire <ca...@ma... (mailto:ca...@ma...)> writes:

> Greetings!
>
> Richard Fateman <fa...@gm... (mailto:fa...@gm...)> writes:
>
>> I think that using exactly the same argument conventions and names as the library would be best.
>> so you overwrite one (or more) of the inputs, for the same reasons as mpfr does it,
>> to save memory allocation when possible.
>>
>> Possible glitch:  it assumes you will only pass arguments that are in memory, not on a stack.
>> Thus for actual use you may need to have a functional style program interface that puts the
>> arguments in memory.  I think that mpfr number structures have a size [maximum length] and
>> an actual size in use. So numbers and comparisons of them etc. must be
>> done by mpfr.
>
> Yes this is the rub, and I believe the basic issues are the same with
> floats as integers.  GCL stores immediate fixnums in one format, other
> fixnums in another, and bignums in a format directly accessible to gmp.
> We could expose both the raw gmp interface and the 'functional'
> interface which would load the first two into the third, but whether
> done under the hood or by the user directly, there is nothing to
> overwrite if fixnums are supplied as output arguments.  At the C level
> we have 5 bignum 'registers' which we do not expose to lisp, as if they
> contain fixnums the logic pertaining to the same will fail.  I suppose
> an expert user could make use of the registers and be careful not to
> refer to them until the gmp calculation is done.
>
> Take care,
>
>> RJF
>>
>> On Wed, Feb 28, 2024 at 12:55 PM Camm Maguire <ca...@ma... (mailto:ca...@ma...)> wrote:
>>
>>  Greetings!
>>
>>  Richard Fateman <fa...@gm... (mailto:fa...@gm...)> writes:
>>
>>  > Several of us here have worked on arbitrary-precision floats in Lisp
>>  > (generally used for longer than double, though I suppose shorter could
>>  > also be specified...), and I think the real win would be to make use
>>  > of the mpfr library (written in C with various assembly-language hacks
>>  > for different CPUs).
>>
>>  mpfr would be a straightforward extension to GCL, as we already use the
>>  gmp integer library, integrate it with our gbc/memory management, and
>>  export the functions at the lisp user level:
>>
>>  >(gmp:mpz_mul most-positive-fixnum most-positive-fixnum)
>>
>>  85070591730234615847396907784232501249
>>
>>  The only sensible way to interface to a library like this is to keep all
>>  the function names and calling syntax the same.  GMP is written with
>>  'side-effects', i.e. destructive modification of the supplied arguments
>>  one or more of which are considered outputs.  This is so the savvy user
>>  can avoid unnecessary allocations, which are effectively all that matter
>>  for performance.  Lisp is so functionally oriented, however, that it
>>  seemed better to me to take only input variables as arguments.  The
>>  natural alternative to the call above would take three arguments,
>>  overwrite the first, and return no values.  Your thoughts?
>>
>>  Take care,
>>  --
>>  Camm Maguire                                        ca...@ma... (mailto:ca...@ma...)
>>  ==========================================================================
>>  "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>>
>
> --
> Camm Maguire                                      ca...@ma... (mailto:ca...@ma...)
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: [Maxima-discuss] +-Inf and NaN

[Richard F. <fa...@gm...>]

In order to use NaN mantissas as payloads for other data,
I think we need something to break the abstraction. Are these features
available in any lisp?
I would think that given a NaN N,   that we could look at its insides by
(integer-decode-float N)
   but (following (setf sb-int:set-floating-point-modes :traps nil)
SBCL says "Can't decode NaN or infinity")
... normally integer-decode-float  would return 3 values.
mantissa, exponent, sign.

 So fixing it would allow us to "read" the payload.
Actually we may need 2,  to decode a single and a double...
integer-decode-single-float  etc.
Or maybe just (decode-double-nan...) to give just the mantissa.


The reverse of this could look like a functional program...
(construct-double-float-from-integers  mantissa exponent sign)
or destructive one(s)
(insert-single-mantissa target value)
(insert-single-exponent target value)
... etc. double..

or (setf (integer-mantissa N)  value)

These facilities would make it feasible to use NaNs for something..
Thanks.

RJF



.


On Fri, Mar 1, 2024 at 8:52 AM Matt Kaufmann <kau...@cs...> wrote:

> Hi Camm,
>
> Since this thread has discussed floating-point exceptions, I'll weigh
> in only by requesting that such behavior will continue to be
> configurable.  Specifically, in ACL2 built using GCL 2.6.12
> (Version_2_6_13pre131), where compilation uses safety 0, then
> evaluation of the following form at start-up gives the behavior I want
> -- in particular, an error when there is floating-point overflow or
> division by zero.
>
> (fpe:break-on-floating-point-exceptions
>  :floating-point-overflow t
>  :floating-point-invalid-operation t)
>
> For example, when I evaluate the definitions
>
> (defun f ()
>   (let ((y (* most-positive-double-float most-positive-double-float)))
>     (= (- y y) 0.0d0)))
>
> and
>
> (defun g ()
>   (= (/ 0.0d0 0.0d0) 0.0d0))
>
> and then compile f and g, then the evaluations of (f) and (g) both
> cause errors, which is what I want.  (If f and g are compiled in gcl
> with safety 0 but are called without first calling
> fpe:break-on-floating-point-exceptions, then there is no error.)
>
> By the way, you asked, regarding other Lisps:
>
> > Can one access/manipulate nan at the lisp prompt level?
>
> See attached, which I think answers your question positively for
> LispWorks, Allegro CL, and CCL, but perhaps negatively for SBCL and
> CMUCL.
>
> Thanks,
> Matt
> Camm Maguire <ca...@ma...> writes:
>
> > Greetings!
> >
> > Richard Fateman <fa...@gm...> writes:
> >
> >> I think that using exactly the same argument conventions and names as
> the library would be best.
> >> so you overwrite one (or more) of the inputs, for the same reasons as
> mpfr does it,
> >> to save memory allocation when possible.
> >>
> >> Possible glitch:  it assumes you will only pass arguments that are in
> memory, not on a stack.
> >> Thus for actual use you may need to have a functional style program
> interface that puts the
> >> arguments in memory.  I think that mpfr number structures have a size
> [maximum length] and
> >> an actual size in use. So numbers and comparisons of them etc. must be
> >> done by mpfr.
> >
> > Yes this is the rub, and I believe the basic issues are the same with
> > floats as integers.  GCL stores immediate fixnums in one format, other
> > fixnums in another, and bignums in a format directly accessible to gmp.
> > We could expose both the raw gmp interface and the 'functional'
> > interface which would load the first two into the third, but whether
> > done under the hood or by the user directly, there is nothing to
> > overwrite if fixnums are supplied as output arguments.  At the C level
> > we have 5 bignum 'registers' which we do not expose to lisp, as if they
> > contain fixnums the logic pertaining to the same will fail.  I suppose
> > an expert user could make use of the registers and be careful not to
> > refer to them until the gmp calculation is done.
> >
> > Take care,
> >
> >> RJF
> >>
> >> On Wed, Feb 28, 2024 at 12:55 PM Camm Maguire <ca...@ma...>
> wrote:
> >>
> >>  Greetings!
> >>
> >>  Richard Fateman <fa...@gm...> writes:
> >>
> >>  > Several of us here have worked on arbitrary-precision floats in Lisp
> >>  > (generally used for longer than double, though I suppose shorter
> could
> >>  > also be specified...), and I think the real win would be to make use
> >>  > of the mpfr library (written in C with various assembly-language
> hacks
> >>  > for different CPUs).
> >>
> >>  mpfr would be a straightforward extension to GCL, as we already use the
> >>  gmp integer library, integrate it with our gbc/memory management, and
> >>  export the functions at the lisp user level:
> >>
> >>  >(gmp:mpz_mul most-positive-fixnum most-positive-fixnum)
> >>
> >>  85070591730234615847396907784232501249
> >>
> >>  The only sensible way to interface to a library like this is to keep
> all
> >>  the function names and calling syntax the same.  GMP is written with
> >>  'side-effects', i.e. destructive modification of the supplied arguments
> >>  one or more of which are considered outputs.  This is so the savvy user
> >>  can avoid unnecessary allocations, which are effectively all that
> matter
> >>  for performance.  Lisp is so functionally oriented, however, that it
> >>  seemed better to me to take only input variables as arguments.  The
> >>  natural alternative to the call above would take three arguments,
> >>  overwrite the first, and return no values.  Your thoughts?
> >>
> >>  Take care,
> >>  --
> >>  Camm Maguire
> ca...@ma...
> >>
> ==========================================================================
> >>  "The earth is but one country, and mankind its citizens."  --
> Baha'u'llah
> >>
> >
> > --
> > Camm Maguire                                      ca...@ma...
> >
> ==========================================================================
> > "The earth is but one country, and mankind its citizens."  --
> Baha'u'llah
>

Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

[Henry B. <hb...@pi...>]

Re type inferencing for Common Lisp:

Hi Camm:

As you no doubt know, some of the most sophisticated type inferencing
systems in use today are the Hindley-Milner style inferencers, used
in a number of 'functional programming' languages and an enhanced
version is used in the Rust programming language.

https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system

Hindley-Milner type systems build up a set of equations, which can
be solved for the actual type.  Once the set of equations have been
derived, there is no more 'forwards' or 'backwards' inferencing,
because we're solving for a *static* solution which works in both

directions.

As you know, the traditional Lisp systems provided for a relatively
obvious *forward* inferencing, which is basically a symbolic execution
of the program in the forward direction.

It is also possible to do a similar *backwards* inference by doing a
symbolic execution of the program in the reverse direction.  Except
for very special programs, a typical backwards inference -- by itself --
won't produce very tight range bounds.

It is also possible to do both forwards and backwards inference -- e.g.,
forwards from the parameters of a function to its result type, and backwards
from its result type to the parameters of the function.  Depending upon the
type lattice chosen, such forwards & backwards inferencing process may never
converge -- e.g., producing tighter and tighter bounds, but never a final
static bound.

If a symbolic mathematical system -- e.g., Maxima -- were available, it would
be possible to create type bounds with *symbolic variable parameters* and
create a set of simultaneous equations using those variables, which could then
be solved for final *static* bounds.

Indeed, a number of modern compilers do a quite nice job with the variables
involved in *index arithmetic*, so that the vast majority of bounds checks
in tight loops can be eliminated.

As you might imagine, solving some of the equations generated from such type
bounds simultaneous equations might involve some fairly deep mathematics -- e.g.,
proving from first principles that a series for the sin(x) function will always
fall into the range [-1.0 .. +1.0].  So the knowledge required for such bounds
inferencing will need to be arbitrarily sophisticated.

A comment on 'assert':

A good compiler will notice that 'assert' fails when its predicate argument
evaluates to false at run-time.  Thus, the addumed truth of this predicate
can be utilized later during forwards inferencing, or earlier during backwards
inferencing.  Thus, an 'assert' can be used as a *hint* to the compiler about

how to handle the induction involved when inferencing processes a loop or a
recursion.

One overall goal of the compiler is to convert 'assert' predicates into compile
time *constants* -- i.e., provably true or false at compile time.

Some modern compiler/loader systems -- e.g., Clang/LLVM -- can continue optimizing
even at link/load time, when more specific information is available about the
actual values of the parameters which might be encountered at runtime.

-----Original Message-----
From: Camm Maguire <ca...@ma...>
Sent: Feb 29, 2024 1:04 PM
To: Henry Baker <hb...@pi...>, <ca...@ma...>
Cc: Stavros Macrakis <mac...@gm...>, Richard Fateman <fa...@gm...>, <max...@li...> <max...@li...>
Subject: Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

Greetings!

Henry Baker writes:

> Re symbols/NaNs:



> A long time ago, I was attempting to derive Lisp-style
>
> bounds declarations at compile time using 'forward' and
>
> 'backward' type inferencing.
>

Indeed, GCL at the moment is making some pretty heavy use of bounds
inferencing/propagation. It seems the most efficient way to do this to
me is to define the common bounds as bits in a predefined type vector,
and indeed to use floats to avoid the worst in ratios for corner cases.

One thing I would like to improve is 'backward' type inferencing, so I
am intrigued by your comment. Once one establishes a binding and later
figures out it must have a more restricted type than originally thought,
the straightforward compiler algorithm is to iterate or throw back to
the binding establishment and proceed again with the updated
information. We do this in a few places such as when processing tags in
tagbodies, but the general idea seems horribly inefficient in terms of
compiler speed. What is the best way to collect 'backward' type
inferencing while processing code as few times as possible?

Take care,

>
>
> For the heck of it, I tried my type inferencer out on a
>
> Newton sqrt iteration, and it dutifully tried to do the
>
> computation at compile time, except using Lisp-style 'bounds'
>
> as a data type. Since the Lisp standard requires *rationals*
>
> for declaring numeric bounds, I quickly got bounds with enormous
>
> denominators.
>
>
>
> I never tried using range arithmetic with floating point bounds
>
> as approximations to the rational bounds, but perhaps that might
>
> be the *best* use for FP range arithmetic in Lisp ! So long as
>
> the FP bounds are *always* looser than the rational bounds, then
>
> the FP bounds should still be useful, and the FP type inference
>
> calculations will be far more efficient than the rational type
>
> inference calculations were.
>
>
>
> BTW, I also worked out a system using Henrici *circular arithmetic*
>
> for implementing continued fractions for sqrt's; perhaps not the
>
> fastest way to compute sqrt approximations, but maybe the most
>
> elegant?
>
>
>
> -----Original Message-----
> From: Stavros Macrakis
> Sent: Feb 29, 2024 11:30 AM
> To: Richard Fateman
> Cc:
> Subject: Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?
>


> Won't the Newton iteration typically be wrapped in a while clause? How will the termination condition be evaluated?
>
> On Thu, Feb 29, 2024 at 12:32 AM Richard Fateman wrote:
>
> In the context of taking a numerical program and reusing it
> with partial symbolic input, here's another example..
>
> Here is one step of a newton iteration: x[n+1] = x[n] - f(x[n])/df(x[n])...
>
> newtstep(f,x,val):= block([d:diff(f,x)], val- subst(val, x,f/d));
>
> how does this work? val is a guess... here, a guess the root of x^2-9...
>
> newtstep(x^2-9,x, 5.0); --> returns 3.4
> newtstep(x^2-9,x, 3.4); --> returns 3.023529411764706
> newtstep(x^2-9,x, 3.023529411764706); --> returns 3.00009155413138
> you get the idea.
>
> Now try putting an expression in there for the guess.. [ could use a NaN perhaps]
> newtstep(x^2-9,x,3-eps)$ /* could put 5-eps or anything else...
> newtstep(x^2-9,x,%)$
> newtstep(x^2-9,x,%)$ -->
> -((eps^8-24*eps^7+504*eps^6-6048*eps^5+45360*eps^4-217728*eps^3+653184*eps^2-1119744*eps+839808)/(8*eps^7-168*eps^6+2016*eps^5-15120*eps^4+72576*eps^3-217728*eps^2+373248*eps-279936))
>
> whew! try to understand this by using Taylor expansion..
>
> taylor(%,eps,0, 9) --> 3+eps^8/279936+eps^9/209952
>
> The newtstep program could instead be some large mysterious
> iterative numerical program in a language that normally does not
> allow symbols. But we might fool it by using NaNs as substitutes for symbolic
> expressions.
> If you had this all hooked up via trap handling
> you might get some insight as to how a program works..
>
> RJF
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

--
Camm Maguire ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

Re: [Maxima-discuss] Using Maxima to delete files and directories in a local machine.

[Michel T. <ta...@lp...>]

Like this:

Zbox:~$ mkdir A

Zbox:~$ maxima -q
(%i1) load("operatingsystem");
(%o1)
/usr/share/maxima/5.42.2/share/contrib/operatingsystem/operatingsystem.mac
(%i2) for i from 1 thru 10 do mkdir(string(A/concat(B,i)));
(%o2)                                done
(%i3) for i from 1 thru 10 do if oddp(i) then rmdir(string(A/concat(B,i)));
(%o3)                                done
(%i4)

Exit maxima

Zbox:~$ ls A
B10  B2  B4  B6  B8

Le 01/03/2024 à 18:23, El Observatorio De Matemática a écrit :
> Hi list
>
> I want to handle a folder with more than 70000 files and 50000 
> directories and delete from it several files and directories using 
> Maxima, if it is possible.
> There is a package in contrib named operatingsystem that potentially 
> can do this task but i can not figure out how to use it.
>
-- 
Michel Talon

[Maxima-discuss] Using Maxima to delete files and directories in a local machine.

[El O. De M. <obs...@gm...>]

Hi list

I want to handle a folder with more than 70000 files and 50000 directories
and delete from it several files and directories using Maxima, if it is
possible.
There is a package in contrib named operatingsystem that potentially can do
this task but i can not figure out how to use it.

I tried this:

(%i1) file_search("operatingsystem.mac")$
(%i2) load(%)$
(%i3) for i in "C:\Users\Usuario\Documents\Trabajos en
wxmaxima\MiscRepo\OldSchool\OtherNibble\RosettaCodeData-main\Task\Sudoku" do
if i#"Common-Lisp" or i#"Maxima" then rmdir(i);
do loop: 'in' argument must be a nonatomic expression; found:
"C:UsersUsuarioDocumentsTrabajos en
wxmaximaMiscRepoOldSchoolOtherNibbleRosettaCodeData-main"

 -- an error. To debug this try: debugmode(true);

I did also try with the path in which \ was replaced with /

Can this task be done using Maxima?

Thanks in advance
-- 
https://github.com/Observatorio-de-Matematica

Re: [Maxima-discuss] Maxima and expert systems

[El O. De M. <obs...@gm...>]

Thank you very much for the helpful information.

El jue, 22 feb 2024 a las 13:47, Richard Fateman (<fa...@gm...>)
escribió:

> I know of no expert system that produces results by using Maxima for
> symbolic mathematics.
>
> There exists a possibility of building an expert system by using the
> commands and language
> of Maxima (perhaps with pattern matching), but this is not something I've
> seen, either.
>
> The patterns are targeted at mathematical expressions, not more general
> situations that
> might occur in a typical "if - then -else" knowledge encoding.
>
> There are expert systems that were built in Lisp  (look up OPS5) and Lisp
> is always available
> underneath Maxima.
> RJF
>
>
>
>
> On Thu, Feb 22, 2024 at 7:12 AM El Observatorio De Matemática <
> obs...@gm...> wrote:
>
>> Hi,
>>
>> Although the Maxima manual does not deal with expert systems, a section
>> about rules and patterns is available.
>> Is there any recommended reference material about expert systems suitable
>> for Maxima?
>>
>> Thanks in advance for any insight.
>> --
>> https://github.com/Observatorio-de-Matematica
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>

Re: [Maxima-discuss] +-Inf and NaN

[Matt K. <kau...@cs...>]

Hi Camm,

Since this thread has discussed floating-point exceptions, I'll weigh
in only by requesting that such behavior will continue to be
configurable.  Specifically, in ACL2 built using GCL 2.6.12
(Version_2_6_13pre131), where compilation uses safety 0, then
evaluation of the following form at start-up gives the behavior I want
-- in particular, an error when there is floating-point overflow or
division by zero.

(fpe:break-on-floating-point-exceptions
 :floating-point-overflow t
 :floating-point-invalid-operation t)

For example, when I evaluate the definitions

(defun f ()
  (let ((y (* most-positive-double-float most-positive-double-float)))
    (= (- y y) 0.0d0)))

and

(defun g ()
  (= (/ 0.0d0 0.0d0) 0.0d0))

and then compile f and g, then the evaluations of (f) and (g) both
cause errors, which is what I want.  (If f and g are compiled in gcl
with safety 0 but are called without first calling
fpe:break-on-floating-point-exceptions, then there is no error.)

By the way, you asked, regarding other Lisps:

> Can one access/manipulate nan at the lisp prompt level?

See attached, which I think answers your question positively for
LispWorks, Allegro CL, and CCL, but perhaps negatively for SBCL and
CMUCL.

Thanks,
Matt
Camm Maguire <ca...@ma...> writes:

> Greetings!
>
> Richard Fateman <fa...@gm...> writes:
>
>> I think that using exactly the same argument conventions and names as the library would be best.
>> so you overwrite one (or more) of the inputs, for the same reasons as mpfr does it,
>> to save memory allocation when possible.
>>
>> Possible glitch:  it assumes you will only pass arguments that are in memory, not on a stack.
>> Thus for actual use you may need to have a functional style program interface that puts the
>> arguments in memory.  I think that mpfr number structures have a size [maximum length] and
>> an actual size in use. So numbers and comparisons of them etc. must be
>> done by mpfr.
>
> Yes this is the rub, and I believe the basic issues are the same with
> floats as integers.  GCL stores immediate fixnums in one format, other
> fixnums in another, and bignums in a format directly accessible to gmp.
> We could expose both the raw gmp interface and the 'functional'
> interface which would load the first two into the third, but whether
> done under the hood or by the user directly, there is nothing to
> overwrite if fixnums are supplied as output arguments.  At the C level
> we have 5 bignum 'registers' which we do not expose to lisp, as if they
> contain fixnums the logic pertaining to the same will fail.  I suppose
> an expert user could make use of the registers and be careful not to
> refer to them until the gmp calculation is done.
>
> Take care,
>
>> RJF
>>
>> On Wed, Feb 28, 2024 at 12:55 PM Camm Maguire <ca...@ma...> wrote:
>>
>>  Greetings!
>>
>>  Richard Fateman <fa...@gm...> writes:
>>
>>  > Several of us here have worked on arbitrary-precision floats in Lisp
>>  > (generally used for longer than double, though I suppose shorter could
>>  > also be specified...), and I think the real win would be to make use
>>  > of the mpfr library (written in C with various assembly-language hacks
>>  > for different CPUs).
>>
>>  mpfr would be a straightforward extension to GCL, as we already use the
>>  gmp integer library, integrate it with our gbc/memory management, and
>>  export the functions at the lisp user level:
>>
>>  >(gmp:mpz_mul most-positive-fixnum most-positive-fixnum)
>>
>>  85070591730234615847396907784232501249
>>
>>  The only sensible way to interface to a library like this is to keep all
>>  the function names and calling syntax the same.  GMP is written with
>>  'side-effects', i.e. destructive modification of the supplied arguments
>>  one or more of which are considered outputs.  This is so the savvy user
>>  can avoid unnecessary allocations, which are effectively all that matter
>>  for performance.  Lisp is so functionally oriented, however, that it
>>  seemed better to me to take only input variables as arguments.  The
>>  natural alternative to the call above would take three arguments,
>>  overwrite the first, and return no values.  Your thoughts?
>>
>>  Take care,
>>  --
>>  Camm Maguire                                        ca...@ma...
>>  ==========================================================================
>>  "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>>
>
> --
> Camm Maguire			     		    ca...@ma...
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

[Camm M. <ca...@ma...>]

Greetings!

Henry Baker <hb...@pi...> writes:

> Re symbols/NaNs:
>
>  
>
> A long time ago, I was attempting to derive Lisp-style
>
> bounds declarations at compile time using 'forward' and
>
> 'backward' type inferencing.
>

Indeed, GCL at the moment is making some pretty heavy use of bounds
inferencing/propagation.  It seems the most efficient way to do this to
me is to define the common bounds as bits in a predefined type vector,
and indeed to use floats to avoid the worst in ratios for corner cases.

One thing I would like to improve is 'backward' type inferencing, so I
am intrigued by your comment.  Once one establishes a binding and later
figures out it must have a more restricted type than originally thought,
the straightforward compiler algorithm is to iterate or throw back to
the binding establishment and proceed again with the updated
information.  We do this in a few places such as when processing tags in
tagbodies, but the general idea seems horribly inefficient in terms of
compiler speed.  What is the best way to collect 'backward' type
inferencing while processing code as few times as possible?

Take care,

>  
>
> For the heck of it, I tried my type inferencer out on a
>
> Newton sqrt iteration, and it dutifully tried to do the
>
> computation at compile time, except using Lisp-style 'bounds'
>
> as a data type.  Since the Lisp standard requires *rationals*
>
> for declaring numeric bounds, I quickly got bounds with enormous
>
> denominators.
>
>  
>
> I never tried using range arithmetic with floating point bounds
>
> as approximations to the rational bounds, but perhaps that might
>
> be the *best* use for FP range arithmetic in Lisp !  So long as
>
> the FP bounds are *always* looser than the rational bounds, then
>
> the FP bounds should still be useful, and the FP type inference
>
> calculations will be far more efficient than the rational type
>
> inference calculations were.
>
>  
>
> BTW, I also worked out a system using Henrici *circular arithmetic*
>
> for implementing continued fractions for sqrt's; perhaps not the
>
> fastest way to compute sqrt approximations, but maybe the most
>
> elegant?
>
>  
>
> -----Original Message-----
> From: Stavros Macrakis <mac...@gm...>
> Sent: Feb 29, 2024 11:30 AM
> To: Richard Fateman <fa...@gm...>
> Cc: <max...@li...> <max...@li...>
> Subject: Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?
>
>  
>
> Won't the Newton iteration typically be wrapped in a while clause? How will the termination condition be evaluated?
>
> On Thu, Feb 29, 2024 at 12:32 AM Richard Fateman <fa...@gm...> wrote:
>
>  In the context of taking a numerical program and reusing it 
>  with partial symbolic input, here's another example..
>   
>  Here is one step of a newton iteration:  x[n+1] = x[n] - f(x[n])/df(x[n])... 
>   
>  newtstep(f,x,val):= block([d:diff(f,x)], val-  subst(val, x,f/d));
>   
>  how does this work?  val is a guess... here, a guess the root of x^2-9...
>   
>  newtstep(x^2-9,x, 5.0);  --> returns 3.4
>  newtstep(x^2-9,x, 3.4);  --> returns 3.023529411764706
>   newtstep(x^2-9,x, 3.023529411764706); --> returns 3.00009155413138
>     you get the idea.
>   
>  Now try putting an expression in there for the guess.. [ could use a NaN perhaps]
>  newtstep(x^2-9,x,3-eps)$ /* could put 5-eps or anything else...
>    newtstep(x^2-9,x,%)$  
>    newtstep(x^2-9,x,%)$    --> 
>      -((eps^8-24*eps^7+504*eps^6-6048*eps^5+45360*eps^4-217728*eps^3+653184*eps^2-1119744*eps+839808)/(8*eps^7-168*eps^6+2016*eps^5-15120*eps^4+72576*eps^3-217728*eps^2+373248*eps-279936))
>   
>  whew!   try to understand this by using Taylor expansion..
>   
>    taylor(%,eps,0, 9) -->  3+eps^8/279936+eps^9/209952
>   
>  The newtstep program could instead be some large mysterious
>   iterative numerical program in a language that normally does not
>  allow symbols. But we might fool it by using NaNs as substitutes for symbolic
>  expressions. 
>  If you had this all hooked up via trap handling 
>  you might get some insight as to how a program works..
>   
>  RJF
>   
>   
>  _______________________________________________
>  Maxima-discuss mailing list
>  Max...@li...
>  https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

-- 
Camm Maguire			     		    ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

[Henry B. <hb...@pi...>]

Re symbols/NaNs:

A long time ago, I was attempting to derive Lisp-style
bounds declarations at compile time using 'forward' and
'backward' type inferencing.

For the heck of it, I tried my type inferencer out on a
Newton sqrt iteration, and it dutifully tried to do the
computation at compile time, except using Lisp-style 'bounds'
as a data type.  Since the Lisp standard requires *rationals*
for declaring numeric bounds, I quickly got bounds with enormous
denominators.

I never tried using range arithmetic with floating point bounds
as approximations to the rational bounds, but perhaps that might
be the *best* use for FP range arithmetic in Lisp !  So long as
the FP bounds are *always* looser than the rational bounds, then
the FP bounds should still be useful, and the FP type inference
calculations will be far more efficient than the rational type
inference calculations were.

BTW, I also worked out a system using Henrici *circular arithmetic*
for implementing continued fractions for sqrt's; perhaps not the
fastest way to compute sqrt approximations, but maybe the most
elegant?

-----Original Message-----
From: Stavros Macrakis <mac...@gm...>
Sent: Feb 29, 2024 11:30 AM
To: Richard Fateman <fa...@gm...>
Cc: <max...@li...> <max...@li...>
Subject: Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

Won't the Newton iteration typically be wrapped in a while clause? How will the termination condition be evaluated?


On Thu, Feb 29, 2024 at 12:32 AM Richard Fateman <fa...@gm... (mailto:fa...@gm...)> wrote:
In the context of taking a numerical program and reusing itwith partial symbolic input, here's another example..
 
Here is one step of a newton iteration:  x[n+1] = x[n] - f(x[n])/df(x[n])... 
newtstep(f,x,val):= block([d:diff(f,x)], val-  subst(val, x,f/d));
 
how does this work?  val is a guess... here, a guess the root of x^2-9...
 
newtstep(x^2-9,x, 5.0);  --> returns 3.4
newtstep(x^2-9,x, 3.4);  --> returns 3.023529411764706
 newtstep(x^2-9,x, 3.023529411764706); --> returns 3.00009155413138
   you get the idea.
 
Now try putting an expression in there for the guess.. [ could use a NaN perhaps]
newtstep(x^2-9,x,3-eps)$ /* could put 5-eps or anything else...
  newtstep(x^2-9,x,%)$  
  newtstep(x^2-9,x,%)$    --> 
    -((eps^8-24*eps^7+504*eps^6-6048*eps^5+45360*eps^4-217728*eps^3+653184*eps^2-1119744*eps+839808)/(8*eps^7-168*eps^6+2016*eps^5-15120*eps^4+72576*eps^3-217728*eps^2+373248*eps-279936))
 
whew!   try to understand this by using Taylor expansion..
 
  taylor(%,eps,0, 9) -->  3+eps^8/279936+eps^9/209952
 
The newtstep program could instead be some large mysterious
 iterative numerical program in a language that normally does not
allow symbols. But we might fool it by using NaNs as substitutes for symbolic
expressions. 
If you had this all hooked up via trap handling 
you might get some insight as to how a program works..
 
RJF
 
 


_______________________________________________
Maxima-discuss mailing list
Max...@li... (mailto:Max...@li...)
https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

[Stavros M. <mac...@gm...>]

I wonder if anyone is using NaN payloads to add, say, high-precision
numbers or numerical differentiation or intervals arithmetic?
Similar to using it for symbolic calculation but should be simpler....

On Thu, Feb 29, 2024 at 2:48 PM Richard Fateman <fa...@gm...> wrote:

> Typically, yes the Newton iteration would be terminated either
> when the result is deemed close enough/ but not always.
>
> A really fast sqrt program might start with pretty good initial
> guess and an in-line expansion of 2 iterations.
>
> See https://en.algorithmica.org/hpc/arithmetic/rsqrt/  for a fun
> exposition of
> how to compute sqrt(1/x) using 1 Newton step. Maybe 2.
>
> There is the well-known potential to understand (or debug or optimize)
> programs by
> "symbolic execution".  This has something of that flavor.
>
>  The novelty presented by using NaNs is that you could
> try to run and better understand a large, opaque, proprietary numerical
> program by
> inserting some NaN(s) in the input and look at the output.
>
>  I am unaware of anyone doing this for real, or
> even an implemented framework by which one could try to do this.
> RJF
>
>
>
>
> On Thu, Feb 29, 2024 at 11:30 AM Stavros Macrakis <mac...@gm...>
> wrote:
>
>> Won't the Newton iteration typically be wrapped in a *while* clause? How
>> will the termination condition be evaluated?
>>
>> On Thu, Feb 29, 2024 at 12:32 AM Richard Fateman <fa...@gm...>
>> wrote:
>>
>>> In the context of taking a numerical program and reusing it
>>> with partial symbolic input, here's another example..
>>>
>>> Here is one step of a newton iteration:  x[n+1] = x[n] -
>>> f(x[n])/df(x[n])...
>>>
>>> newtstep(f,x,val):= block([d:diff(f,x)], val-  subst(val, x,f/d));
>>>
>>> how does this work?  val is a guess... here, a guess the root of x^2-9...
>>>
>>> newtstep(x^2-9,x, 5.0);  --> returns 3.4
>>> newtstep(x^2-9,x, 3.4);  --> returns 3.023529411764706
>>>  newtstep(x^2-9,x, 3.023529411764706); --> returns 3.00009155413138
>>>    you get the idea.
>>>
>>> Now try putting an expression in there for the guess.. [ could use a NaN
>>> perhaps]
>>> newtstep(x^2-9,x,3-eps)$ /* could put 5-eps or anything else...
>>>   newtstep(x^2-9,x,%)$
>>>   newtstep(x^2-9,x,%)$    -->
>>>
>>>   -((eps^8-24*eps^7+504*eps^6-6048*eps^5+45360*eps^4-217728*eps^3+653184*eps^2-1119744*eps+839808)/(8*eps^7-168*eps^6+2016*eps^5-15120*eps^4+72576*eps^3-217728*eps^2+373248*eps-279936))
>>>
>>> whew!   try to understand this by using Taylor expansion..
>>>
>>>   taylor(%,eps,0, 9) -->  3+eps^8/279936+eps^9/209952
>>>
>>> The newtstep program could instead be some large mysterious
>>>  iterative numerical program in a language that normally does not
>>> allow symbols. But we might fool it by using NaNs as substitutes for
>>> symbolic
>>> expressions.
>>> If you had this all hooked up via trap handling
>>> you might get some insight as to how a program works..
>>>
>>> RJF
>>>
>>>
>>> _______________________________________________
>>> Maxima-discuss mailing list
>>> Max...@li...
>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>>
>>

Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

[Richard F. <fa...@gm...>]

Typically, yes the Newton iteration would be terminated either
when the result is deemed close enough/ but not always.

A really fast sqrt program might start with pretty good initial
guess and an in-line expansion of 2 iterations.

See https://en.algorithmica.org/hpc/arithmetic/rsqrt/  for a fun exposition
of
how to compute sqrt(1/x) using 1 Newton step. Maybe 2.

There is the well-known potential to understand (or debug or optimize)
programs by
"symbolic execution".  This has something of that flavor.

 The novelty presented by using NaNs is that you could
try to run and better understand a large, opaque, proprietary numerical
program by
inserting some NaN(s) in the input and look at the output.

 I am unaware of anyone doing this for real, or
even an implemented framework by which one could try to do this.
RJF




On Thu, Feb 29, 2024 at 11:30 AM Stavros Macrakis <mac...@gm...>
wrote:

> Won't the Newton iteration typically be wrapped in a *while* clause? How
> will the termination condition be evaluated?
>
> On Thu, Feb 29, 2024 at 12:32 AM Richard Fateman <fa...@gm...>
> wrote:
>
>> In the context of taking a numerical program and reusing it
>> with partial symbolic input, here's another example..
>>
>> Here is one step of a newton iteration:  x[n+1] = x[n] -
>> f(x[n])/df(x[n])...
>>
>> newtstep(f,x,val):= block([d:diff(f,x)], val-  subst(val, x,f/d));
>>
>> how does this work?  val is a guess... here, a guess the root of x^2-9...
>>
>> newtstep(x^2-9,x, 5.0);  --> returns 3.4
>> newtstep(x^2-9,x, 3.4);  --> returns 3.023529411764706
>>  newtstep(x^2-9,x, 3.023529411764706); --> returns 3.00009155413138
>>    you get the idea.
>>
>> Now try putting an expression in there for the guess.. [ could use a NaN
>> perhaps]
>> newtstep(x^2-9,x,3-eps)$ /* could put 5-eps or anything else...
>>   newtstep(x^2-9,x,%)$
>>   newtstep(x^2-9,x,%)$    -->
>>
>>   -((eps^8-24*eps^7+504*eps^6-6048*eps^5+45360*eps^4-217728*eps^3+653184*eps^2-1119744*eps+839808)/(8*eps^7-168*eps^6+2016*eps^5-15120*eps^4+72576*eps^3-217728*eps^2+373248*eps-279936))
>>
>> whew!   try to understand this by using Taylor expansion..
>>
>>   taylor(%,eps,0, 9) -->  3+eps^8/279936+eps^9/209952
>>
>> The newtstep program could instead be some large mysterious
>>  iterative numerical program in a language that normally does not
>> allow symbols. But we might fool it by using NaNs as substitutes for
>> symbolic
>> expressions.
>> If you had this all hooked up via trap handling
>> you might get some insight as to how a program works..
>>
>> RJF
>>
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>

Re: [Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

[Stavros M. <mac...@gm...>]

Won't the Newton iteration typically be wrapped in a *while* clause? How
will the termination condition be evaluated?

On Thu, Feb 29, 2024 at 12:32 AM Richard Fateman <fa...@gm...> wrote:

> In the context of taking a numerical program and reusing it
> with partial symbolic input, here's another example..
>
> Here is one step of a newton iteration:  x[n+1] = x[n] -
> f(x[n])/df(x[n])...
>
> newtstep(f,x,val):= block([d:diff(f,x)], val-  subst(val, x,f/d));
>
> how does this work?  val is a guess... here, a guess the root of x^2-9...
>
> newtstep(x^2-9,x, 5.0);  --> returns 3.4
> newtstep(x^2-9,x, 3.4);  --> returns 3.023529411764706
>  newtstep(x^2-9,x, 3.023529411764706); --> returns 3.00009155413138
>    you get the idea.
>
> Now try putting an expression in there for the guess.. [ could use a NaN
> perhaps]
> newtstep(x^2-9,x,3-eps)$ /* could put 5-eps or anything else...
>   newtstep(x^2-9,x,%)$
>   newtstep(x^2-9,x,%)$    -->
>
>   -((eps^8-24*eps^7+504*eps^6-6048*eps^5+45360*eps^4-217728*eps^3+653184*eps^2-1119744*eps+839808)/(8*eps^7-168*eps^6+2016*eps^5-15120*eps^4+72576*eps^3-217728*eps^2+373248*eps-279936))
>
> whew!   try to understand this by using Taylor expansion..
>
>   taylor(%,eps,0, 9) -->  3+eps^8/279936+eps^9/209952
>
> The newtstep program could instead be some large mysterious
>  iterative numerical program in a language that normally does not
> allow symbols. But we might fool it by using NaNs as substitutes for
> symbolic
> expressions.
> If you had this all hooked up via trap handling
> you might get some insight as to how a program works..
>
> RJF
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] +-Inf and NaN

[Camm M. <ca...@ma...>]

Greetings!

Richard Fateman <fa...@gm...> writes:

> I think that using exactly the same argument conventions and names as the library would be best.
> so you overwrite one (or more) of the inputs, for the same reasons as mpfr does it,
> to save memory allocation when possible.  
>
> Possible glitch:  it assumes you will only pass arguments that are in memory, not on a stack.
> Thus for actual use you may need to have a functional style program interface that puts the
> arguments in memory.  I think that mpfr number structures have a size [maximum length] and
> an actual size in use. So numbers and comparisons of them etc. must be
> done by mpfr.

Yes this is the rub, and I believe the basic issues are the same with
floats as integers.  GCL stores immediate fixnums in one format, other
fixnums in another, and bignums in a format directly accessible to gmp.
We could expose both the raw gmp interface and the 'functional'
interface which would load the first two into the third, but whether
done under the hood or by the user directly, there is nothing to
overwrite if fixnums are supplied as output arguments.  At the C level
we have 5 bignum 'registers' which we do not expose to lisp, as if they
contain fixnums the logic pertaining to the same will fail.  I suppose
an expert user could make use of the registers and be careful not to
refer to them until the gmp calculation is done.

Take care,

> RJF
>
> On Wed, Feb 28, 2024 at 12:55 PM Camm Maguire <ca...@ma...> wrote:
>
>  Greetings!
>
>  Richard Fateman <fa...@gm...> writes:
>
>  > Several of us here have worked on arbitrary-precision floats in Lisp
>  > (generally used for longer than double, though I suppose shorter could
>  > also be specified...), and I think the real win would be to make use
>  > of the mpfr library (written in C with various assembly-language hacks
>  > for different CPUs).
>
>  mpfr would be a straightforward extension to GCL, as we already use the
>  gmp integer library, integrate it with our gbc/memory management, and
>  export the functions at the lisp user level:
>
>  >(gmp:mpz_mul most-positive-fixnum most-positive-fixnum)
>
>  85070591730234615847396907784232501249
>
>  The only sensible way to interface to a library like this is to keep all
>  the function names and calling syntax the same.  GMP is written with
>  'side-effects', i.e. destructive modification of the supplied arguments
>  one or more of which are considered outputs.  This is so the savvy user
>  can avoid unnecessary allocations, which are effectively all that matter
>  for performance.  Lisp is so functionally oriented, however, that it
>  seemed better to me to take only input variables as arguments.  The
>  natural alternative to the call above would take three arguments,
>  overwrite the first, and return no values.  Your thoughts?
>
>  Take care,
>  -- 
>  Camm Maguire                                        ca...@ma...
>  ==========================================================================
>  "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>

-- 
Camm Maguire			     		    ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

[Maxima-discuss] putting a symbol into a numeric formula, a use for a NaN?

[Richard F. <fa...@gm...>]

In the context of taking a numerical program and reusing it
with partial symbolic input, here's another example..

Here is one step of a newton iteration:  x[n+1] = x[n] - f(x[n])/df(x[n])...

newtstep(f,x,val):= block([d:diff(f,x)], val-  subst(val, x,f/d));

how does this work?  val is a guess... here, a guess the root of x^2-9...

newtstep(x^2-9,x, 5.0);  --> returns 3.4
newtstep(x^2-9,x, 3.4);  --> returns 3.023529411764706
 newtstep(x^2-9,x, 3.023529411764706); --> returns 3.00009155413138
   you get the idea.

Now try putting an expression in there for the guess.. [ could use a NaN
perhaps]
newtstep(x^2-9,x,3-eps)$ /* could put 5-eps or anything else...
  newtstep(x^2-9,x,%)$
  newtstep(x^2-9,x,%)$    -->

  -((eps^8-24*eps^7+504*eps^6-6048*eps^5+45360*eps^4-217728*eps^3+653184*eps^2-1119744*eps+839808)/(8*eps^7-168*eps^6+2016*eps^5-15120*eps^4+72576*eps^3-217728*eps^2+373248*eps-279936))

whew!   try to understand this by using Taylor expansion..

  taylor(%,eps,0, 9) -->  3+eps^8/279936+eps^9/209952

The newtstep program could instead be some large mysterious
 iterative numerical program in a language that normally does not
allow symbols. But we might fool it by using NaNs as substitutes for
symbolic
expressions.
If you had this all hooked up via trap handling
you might get some insight as to how a program works..

RJF